Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/networking/terms/kermit/c/hpbker.bwr

Internet Message Format | 1989-05-13 | 9.4 KB

Date: Thu, 27 Apr 89 15:17 EST
From: Roger Wallace <[e-mail]>
Subject: HP-9000 Kermit Bootstraping Methods
Keywords: HP-9000, Bootstrapping

 Alternative Methods for Bootstrapping KERMIT-RMB to
         HP-9000 series Workstations.

     We have now successfully bootstrapped Kermit-RMB to several HP-9000
series workstations, and are in the process of gathering user feedback on
the performance of this new version.  This particular Kermit fills a long-
standing need for reliable file transfer to hosts outside of the HP family.
The basic terminal emulation and file transfer facilities seem to work as
they should; we will forward any bug reports from our user community both
to the Digest and to Andy Campagnola.  In the meantime, I thought I would
pass along, as alternatives, the methods we tried for getting the appropriate
files into HP-LIF disks.

     1). Raw Capture:  One of our groups tried simple raw capture of the
HPBKER.BAS file from a local VAX host to the HP-9000 workstation.  The
interpreted BASIC program appeared to load and start properly, but no external
communications could be established.  The particular workstation involved was
running a pre-5.0 BASIC and lacked the BASIC compiler.  Kermit-RMB apparently
makes system calls not supported under older BASIC versions, so a working
Kermit was not produced (no surprise!).  With the proper revision level of
HP-BASIC, and the BASIC compiler for generating the compiled subroutines, we
believe (from the "partial" success) that raw capture over "clean" local lines
is a viable approach for bootstrapping the program from a mainframe.

     2). Decode .HEX files:  This approach provided our first successful
installation, although circumstances forced us to use a technique different
from that suggested in HPBAAA.HLP.  We had an MS-DOS PC on which the DOS/HPW
to LIF conversion could be run, but no C-compiler for the "UNHEX.C" program,
and no alternative PC "unhex" program.  However, I did have in my lab several
PDP-11's running TSX+, and happened to recall that Brian Nelson had included
a hex-dehex program in the Kermit-11 distribution.  Brian's K11HEX.FTN was
pulled from our library and hastily adapted to the problem at hand; the HEX
decodes were run on a PDP-11, and the resulting "binaries" were shipped to the
PC (Kermit-11 in binary mode to Kermit-MS).  Once the binaries were on the PC,
HPWUTIL.EXE was run on the PC both to format LIF diskettes, 5.25-inch in our
case, and to write all of the LIF files needed to build Kermit-RMB.  Success
of this approach depends on the fact that both RT-11/TSX+ and MS-DOS store
binary files as simple, undelimited byte strings;  The two Kermits provided
the required eight-bit data path between the two machines.

     To aid anyone interested in this eccentric, but functional, method
for generating Kermit-RMB, I have appended the FORTRAN source for our modified
version of K11HEX.FTN, called HPBDEH.F77, to this message.  A few points must
be noted about our decoding scheme.  First, the original K11HEX program used a
very robust coding scheme in which the HEX files consisted of a 64-byte "data"
field, together with a checksum field, on each line.  Our bare-bones adapta-
tion omits the checksum routine, since HPB*.HEX files are simple HEX-encodes,
and as a result it requires HEX-source files with 64 characters per line.  We
reformatted the HEX files in the distribution to accommodate this requirement.
(This reformatting would be transparent to "UNHEX.C" which ignores end-of-line
codes anyway.)  Second, in writing the decoded output file, both K11HEX and
HPBDEH conform to the "integral number of blocks" file-length requirement of
the RT-11 and TSX+ operating systems.  As luck would have it, most of the
decoded files met this requirement -- LIF files are an integral number of
256-byte sectors ("half-blocks" to RT-11) long.  In three cases, however, it
was necessary to pad the distributed HEX files so the decodes would come out
"even".  The following "pads" were added at the ends of the HEX files listed:

     HPBINI.HEX -- 8 lines of 64 'F' characters each (continued the pattern
                   for "empty" space in the distribution file)

     HPBMIS.HEX -- 8 lines of 64 '0' (zero) characters each

     HPBWUT.HEX -- 334 '0' (zero) characters; 14 completed the final line
                   of the distributed file which was "short" after the con-
                   version to 64-character-per-line format; an additional
                   5 lines of 64 zeros each completed the pad to the end of
                   the block in the decoded file.

     Apparently, when HPWUTIL.EXE does the conversion to LIF-format files,
it makes use of the file length information in HPWLIF.DIR, and the padded
DOS files are truncated to produce LIF files of the correct length.  The
first two files would probably have worked regardless of the "pad" character
used.  The NUL padding of HPWUTIL.EXE produced by adding the zeros at the end
of HPBWUT.HEX seemed to have no effect on the operation of the DOS-executable
program.  Good luck again!

    We can supply the reformatted and padded HEX files if there is any
real interest, but bootstrapping method (3) below will probably render
the hex-dehex method obsolete in the future.  Also, our HPBDEH program offers
very little protection against corrupted HEX files.  It will abort if it hits
a "hard" read error (defective medium), but it will produce output files
from HEX sources that contain "illegal" HEX characters, have short or long
lines, i.e. missing or superfluous characters, or even have missing or
excess lines.

    3). "De-BOO" the .BOO files: Our final bootstrapping method, which has
also been successful, really represents a suggestion for the method of dis-
tributing Kermit-RMB.  The reasoning behind this approach is as follows:
for the time being, the use of an MS-DOS machine as an "intermediary" at some
point in the building of Kermit-RMB will be required for the DOS/HPW to LIF
format conversion.  Since most sites using the HP-9000 series machines would
probably have access to an IBM PC or clone, why not use the utilities in the
Kermit-MS distribution for the encode-decode required to eliminate the "funny"
characters in the DOS/HPW files.  Specifically, use MSBMKB.EXE to encode
the DOS/HPW files to ".BOO" form, and MSBPCT.EXE to decode the *.BOO files
after network transmission and download.  An added bonus is that the .BOO
files are shorter than the .HEX files.  Utilities MSBMKB.EXE and MSBPCT.EXE
can be assembled from the Kermit-MS distribution.  The HPB*.HEX distribution
can be retained for use by those sites which must receive files over EBCDIC
links, where problems in handling .BOO files sometimes arise.

     To test the BOO -- DE-BOO sequence, we took our set of "reference"
Kermit-RMB LIF-format files and used HPWUTIL.EXE to convert these back to
DOS/HPW format on the PC.  These were BOO-encoded and decoded in the MS-DOS
environment.  The DOS/HPW files so treated grew by three bytes (NUL-NUL-SUB)
each; i.e., they acquired an explicit MS-DOS end-of-file mark.  This small
"tail" was lopped off by HPWUTIL.EXE when encoded-decoded files were trans-
formed back to LIF format.  Viewed at the HP-LIF file level, the complete set
of conversions (LIF->DOS->BOO->DOS->LIF) caused no change in the files.  As
for HPWUTIL.EXE, which must actually live and work at the DOS level, the extra
bytes seem to cause no difficulty.  Our BOO - DE-BOO'ed version runs just like
the "original" HEX-decoded version.

     A couple of additional notes about the HPWUTIL.EXE program:  First, there
seems to be no direct way to convert a single DOS/HPW file to LIF format.  The
utility works on complete DOS/HPW file subsystems.  This causes no problem if
you are writing the Kermit-RMB files to a 3.5" LIF-formatted floppy; the whole
distribution fits on one diskette, and a single command sequence accomplishes
the entire conversion.  For 5.25" floppies, where two diskettes are required
to hold the complete distribution, we resorted to the following "game": start
with all of the DOS/HPW files, including HPWLIF.DIR, in a DOS sub-directory,
and a blank LIF-formatted floppy in the destination drive.  Give the copy com-
mands as described in the HPBAAA.HLP file.  The conversion will run until
insufficient space remains on the floppy.  Note which files were successfully
converted.  Delete the corresponding DOS/HPW files from the DOS subdirectory.
Place the second blank LIF-formatted diskette in the drive and re-run the
conversion procedure.  This time, HPWUTIL.EXE will note that it can't find all
of the files, specifically the ones successfully converted on the first pass
and subsequently deleted, but will convert the remaining DOS/HPW files to
LIF-format on the second floppy.

     The second note: if you run a LIF-to-DOS/HPW conversion as we did in the
course of checking the BOO -- DE-BOO sequence, be aware that the DOS file
HPWLIF.DIR will be created in "Read-Only" mode.  It will be necessary to issue
the DOS command "ATTRIB -R HPWLIF.DIR" before the file can be deleted with the
usual "DEL" command.

     And finally, our thanks again to Andy Campagnola and his associates
at HP for making a much-needed Kermit implementation available.

                                             Roger Wallace
                                             Research Division
                                             Raytheon Co.
                                             Lexington, MA

------------------------------